Issues with ViewFactories:

• main view factory should not be swing specific
• a object that is using a view factory should be able to ask for a particular type of view currently:
  • jcomponent
  • xhtml
• the view factory needs to do specific types of initialization for different view types currently:
  • jcomponent
    • needs to handle ViewFactoryAware, ViewContainerAware, FrameManagerAware
  • xhtml (has no initialization needs)
    • might want to have screen resolution if it generating images.
  • these initializations need inputs from the environment:
    • viewContainer, frameManager, screen resolution

• a object using the view factory that asks for a JComponent from an object or viewEntry that is XHTML should
  get back a JComponent that wraps that, so the object doesn't need to care.
• same with an object wanting xhtml, if it asks for that from a JComponent view the viewFactory should hand back
  a wrapper that returns a chunk of xhtml with an image of the component.

• viewFactories should be nestable, so different contexts can return different types of views. An example is the report
  tool. In one place it uses multi-user views, in the other it uses single user views.

Because of these requirements there cannot be a single view factory, or lots of subclassed view factories.
Because an object that asks for a SwingViewFactory will want it to handle xhtml views too.

So the viewFactory needs to have "plugins", of sorts.
It could work two ways.

Way 1
An object using the view factory would do:
Object viewFactory.getViewInstance(Object otObject, Class viewType, ViewEntry viewEntry);
The view factory would then lookup the plugin for handling the viewType, and that plugin would need to
be initialized with the appropriate stuff.

However this won't fit the "viewContainer" approach. Each object that request a JComponent should provide
a view container, so the returned object can change itself.

Way 2
An object using the view factory would do:
OTViewHandler viewFactory.getViewHandler(Class viewType);
then the object would have to cast that the viewHandler that they want. Something like:
a SwingViewHandler.
And then SwingViewHandler would have methods:
JComponent getJComponnet(otObject, viewContainer);

Way 3
An object use a view factory would mark itself as:
SwingViewFactory/Handler aware.
Then this would be set when it is started up. But this would still be connected to the master viewFactory
so the views can be setup in one place but objects can use them through different view specific ways.

Interesting Cases

Choice Object

The choice object has two views:

• PfChoiceView, which is a JComponent
• PfChoiceMultiUserView, which is a XHTML view

When displaying a PfChoice directly on the left, a JComponent view is requested by calling getComponent on the view factory.
When displaying a PfChoice inside of a PfQuery view the JComponent is requested because it has been special cased.
When displaying a PfChoice directly using a reference to it from the bodyText of an OTDocument, then the OTDocument requests the OTXHTML view first, and finds one. But when it tries to use this view, it fails because, it isn't in multi user mode. Even if this worked it would be the wrong thing. What is needed here is the JComponent view, but how is it supposed to be setup for this?

Options:

• the reference to the PfChoice object could explicitly reference the JComponent view
• the mechanism for looking up views needs to have more options. In this case some control should be given to the PfChoice views, so they can say: when I'm being requested in a OTDocument, single user, and student mode. Then return the JComponent. Student Mode can be specified as the default.
  • if the OTDocument had its own viewFactory which could be plugged into, then the PfChoice could plug into it and specify that the JComponent view is better than the XHTML view for choices.

Text Object

The text object should have lots of views:

• multiple sized text boxes that can be used to edit the text object
• labels for read only text objects
• xhtml views for read only xhtml rendering.

If the view of the object is specified when it is used then these will not be a problem. Perhaps that is the best solution for the above problem too. If it turns out that this is too cumbersome, a custom OTClass could be created which has a default view of one of the above, then objects of that custom OTClass can be embedded and they will be rendered properly. This approach has the benifit of not tying the content directly to a particular view, instead it just has the OTClass which then figures out the correct view. It isn't clear this will solve the problem though, we'll need to work through cases to figure it out.